Lossless account compression for health care patient benefits eligibility research system and methods

ABSTRACT

A system and method for determining eligibility for reimbursement for medical claims for patients may be implemented with computer software which compares a service provider&#39;s patient information against a benefit provider&#39;s database of covered persons to determine if the patient is eligible for benefits. The service provider records may be compressed by grouping all of the medical claims relating to a particular patient into one cluster represented by a composite medical claim, which may be used to query the benefit provider databases to determine if the patient is recognized. If the patient is recognized, every record within the cluster may be checked against the benefit provider&#39;s database to determine whether one or more patient medical claims are eligible for reimbursement.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent applicationSer. No. 11/098,295 filed Apr. 4, 2005, which claims the benefit of U.S.Provisional Patent Application No. 60/654,028 filed Feb. 17, 2005.

FIELD

This application relates generally to data processing software forinquiring and determining eligibility for reimbursement for medicalclaims for patients by comparing the patient information of a serviceprovider against a benefit provider's database of covered persons todetermine if the patient is eligible for benefits and, if so,associating the patient record with the matching record in the benefitprovider's database so the service provider can seek to be reimbursedfor the health care services provided to the patient.

BACKGROUND

The provision of health care services in the United States has becomethe focus of much attention. With the costs of medical malpracticeinsurance spiraling, and the payments being made to health careproviders from benefit providers, including private and governmentinsurers, being reduced continually, health care providers are findingit necessary to get payments for all the services they actually render.

Unfortunately, many health care providers are not receiving compensationfor the services they render. This could be due to a number of factors,such as patients not having the ability to pay for the services, and/ornot having any medical payment system or insurance. In other instances,medical care service providers submit a request to determine if apatient is eligible for coverage under a private or government insuranceplan, but are told the patient is not eligible for coverage. Often,payment for services rendered is denied due to incorrect data entryabout a patient and/or the service rendered, through failure toassociate the information with the correct patient record in the benefitprovider's database, or other misunderstandings or mis-associations.

For medical care service providers, being denied payment for servicesrendered is problematic, and can, in some cases, mean the differencebetween profitability and a business that does not show a profit.Typically, such medical claims which are classified as not eligible forreimbursement are written off as bad debt for which collection cannot beachieved. Ultimately, these costs are either passed along to otherpatients by means of cost increases, or the care provided is cut back tosave or reduce costs.

Accordingly, a continuing search has been directed to the development ofmethods which can help medical care service providers maximizeidentification of patients who are eligible for private or governmentmedical insurance so the service providers can be reimbursed for medicalclaims.

Therefore, what is needed is a system and method for helping toefficiently identify medical claims for which the patients are eligiblefor health care benefits, which can be paid to the health care provider.

SUMMARY

Normally, claims for medical care are submitted to a patient's benefitprovider for payment. Prior to submitting the medical claim, the healthcare provider will need to make an eligibility inquiry to determinewhether the person for whom the service was provided is eligible forbenefits; if not, payment to the health care provider will be denied. Inmany cases, the denial is because the information entered on the medicalclaim submitted to the benefit provider by the service provider cannotbe correlated with the information in the benefit provider's databasebecause the patient could not be located in the benefit provider'sdatabase due to inconsistencies. In some instances, this is due to adata entry error on the part of the service provider, benefit provider,or both. In other instances, the patient may not be eligible forinsurance coverage at the time the services are rendered, or when theeligibility verification inquiry is made.

While software already exists that will make an eligibility inquiry todetermine eligibility, and inquire as to correlation between records,there has been only partial success with prior attempts of automatedeligibility verification inquiries. The existing software has onlylimited functionality and is not always effective or accurate. It willtypically only search for records in which the patient's name, socialsecurity number and date of birth match a record in the benefitprovider's database, and it returns a list indicating only thosepatients for which an exact match has been found. It will not provideinformation as to numerous other issues that are related to eligibility,such as whether the service rendered is one paid for by the benefitprovider. Additionally, manual examination is typically not practical orcost-effective, given the volume of patient medical claims and records.Also, some benefit provider systems and databases may not be robustenough to handle the volume of eligibility inquiries being sent, and thesubmission of a large number of medical claims can greatly increase theresponse time.

The system and method disclosed herein may be implemented in a softwareprogram that will automatically, upon request, query benefit providerdatabases with a variety of different queries to find persons who areeligible to receive benefits, and who match patients in a serviceprovider's database for whom services have been or may be provided. Thesoftware may also automatically segregate those records for which thereis a match between the databases for further processing, and it mayindicate the matching information found in the benefit provider'sdatabase. For example, the software may inquire whether the patient iscovered by the benefit plan, whether the services provided are coveredby the benefit plan, and/or whether the provider is authorized toprovide services for persons covered by that benefit plan.

The software described herein may also provide a means for comparingrecords in the benefit provider's database against a service provider'smedical claims and finding records that, while not a complete match,have a predefined number of parameters that match, such that uponfurther analysis and correction, it may be determined that a patientmedical claim is eligible for reimbursement and can be submitted to thebenefit provider, and the service provider will be reimbursed for theservices performed. The software may easily reveal the field or fieldsin which there is a difference in the information between the serviceprovider's medical claim and the benefit provider's database, makingcorrection of any claim errors much simpler and making the presentsystem and method much more cost-effective than previous systems andmethods, which generally did not reveal any such partial matches, orshow errors that had caused a medical claim that was submitted to havebeen rejected, but only verified whether or not there was a completematch.

The software described herein may also compress service provider recordsby, for example, grouping all of the medical claims relating to aparticular patient into one cluster represented by a composite medicalclaim containing all of the relevant search parameters. The software maythen query benefit provider databases with a variety of differentqueries using this composite medical claim to determine if the benefitprovider's database recognizes the patient. If the patient isrecognized, the software may then run every record within the clusteragainst the database to determine whether a patient medical claim iseligible for reimbursement and can be submitted to the benefit providerfor payment. In situations where a significant percentage of accountscome from repeat visits by a patient to a service provider and where thenormal match rate against the benefit provider's database is small, thisaccount compression can result in a significantly reduced transactionload on the benefit provider's database. This process is lossless inthat no eligibilities that would have been found by querying the benefitprovider's database using each individual record are missed or lost byquerying the database using the composite medical claim. The softwareallows more accounts to be run against the benefit provider's databasewithout increasing the strain on the benefit provider's system.

The software described herein may also show whether the patient wasqualified to be covered by a benefit plan at the time the services wererendered. In some instances, the patient may not be eligible forcoverage at the time the initial inquiry is made, but may becomeeligible for coverage at a later time, and the coverage may beretroactive back to a period including the time at which the serviceprovider rendered treatment. If this retroactive eligibility isdiscovered and identified in a timely manner, a request for retroactivereimbursement can be made in some cases.

In other cases, even if the eligibility qualification is not discoveredin time to seek reimbursement, the un-reimbursed medical claims can beimportant for a health care service provider in determining if it isentitled to reimbursement under various government programs for treatinguninsured persons, and to help the service provider keep accurate trackof how much of such funding they might be entitled to.

The present system and method may also be used to generate reports in avariety of configurations, such as to record matches found, to assist inidentifying errors, determining sources of errors, and taking steps toprevent similar future errors. A surprising number of matches betweenservice provider medical claims and benefit provider databases ofpersons eligible for reimbursement were found using embodiments of thesoftware described herein that were not found using prior art software.Even when the software described herein is used to query the samebenefit provider's database for the same health care provider's medicalclaims, matches are found that were not found when the same or similarqueries were previously made. These matches have resulted in tens ofmillions of dollars of reimbursements for service providers that wouldhave otherwise gone unpaid.

The foregoing summary has outlined rather broadly some of the featuresof the system and method described herein in order that the detaileddescription that follows may be better understood. Additional featureswill be described hereinafter. It should be appreciated by those skilledin the art that the concepts and the specific embodiments disclosedherein may be readily utilized as a basis for modifying or designingother structures for carrying out the same or similar purposes. Itshould also be realized by those skilled in the art that such equivalentconstructions do not depart from the spirit and scope of the inventionas set forth in the appended patent claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a high-level conceptual block diagram illustrating anembodiment of the system described herein.

FIG. 1B is a detailed block diagram showing the querying of the benefitprovider database, including comparison of service provider file recordsagainst the benefit provider's database, and generation of one or morefiles containing service provider's records and matching records fromthe benefit provider database.

FIGS. 2A, 2B, and 2C show samples of some of the types of reports thatcan be generated from the file containing service provider medicalclaims for which there is a matching record in the benefit provider'sdatabase.

DETAILED DESCRIPTION

As used herein, the following terms should be understood to have theindicated meanings:

When an item is introduced by “a” or “an,” it should be understood tomean one or more of that item.

“Benefit provider” means an individual or entity that is obligated toprovide payments for the benefit of specified patients for specifiedhealth care services.

“Cluster” means a group of medical claims all relating to the samepatient.

“Composite medical claim” means a collection of data representative ofall the medical claims within a cluster.

“Comprises” means includes but is not limited to.

“Comprising” means including but not limited to.

“Constituent medical claim” means a medical claim within a cluster.

“Database” means a collection of data embodied in at least one computerreadable medium and organized in a suitable way to permit a computer toselect one or more desired portions of such data.

“Eligibility inquiry” means a query as to whether a medical claim issubject to an obligation of payment by a benefit provider.

“Having” means including but not limited to.

“Health care services” means any services that are rendered to addressthe health of a patient. Health care services may include but are notlimited to diagnostic, therapeutic, preventative, and maintenanceservices related to the physical or mental health of a patient.

“Medical claim” means a collection of data relating to one or moreinstances of the provision of health care services to a patient by aservice provider.

“Query” means a request for information from a database.

“Recognized” means, in connection with a patient and a benefitprovider's database, that such benefit provider's database contains datarepresentative of such patient.

“Service provider” means an individual or entity that provides healthcare services to patients.

In the discussion of the figures, the same reference numerals will beused throughout to refer to the same or similar components. In theinterest of conciseness, various other components known in the art, suchas computer processing equipment, and the like necessary for theoperation of the software, have not been shown or discussed.

In the following discussion, numerous specific details are set forth toprovide a thorough understanding of the system and method describedherein. However, it will be obvious to those skilled in the art that thesystem and method may be practiced without such specific details. Inother instances, well known elements have been illustrated in schematicor block diagram form in order not to obscure the disclosure inunnecessary detail. Additionally, for the most part, details concerningtiming considerations and the like have been omitted inasmuch as suchdetails are not considered necessary to obtain a complete understandingof the system and method, and are considered to be within the skills ofpersons of ordinary skill in the relevant art.

It is noted that, unless indicated otherwise, all functions describedherein may be performed by a processor such as a computer or electronicdata processor in accordance with code such as computer program code,software, or integrated circuits that are coded or configured to performsuch functions. Additionally, it is noted that the software describedherein may be used at a computer remote from the benefit provider'scomputer system and from the service provider's computer system, orlocally to either of those computer systems.

A. IMPROVED SYSTEM

Referring to FIG. 1A of the drawings, the reference numeral 1 generallydesignates an improved eligibility verification inquiry system. Theinquiry system 1 comprises unpaid medical claims 100, software 10,benefit provider's database 500, files of matches 400, and reports 450from the files of matches 400.

Normally, medical claims 100 for medical care services are paid for by apatient directly, or submitted to a patient's benefit provider forpayment, such as a private health insurance company, orgovernment-subsidized health care insurance, such as Medicare, Medicaidor other government-funded programs. After processing to verify suchthings as whether the person for whom the service was provided iscovered by the benefit provider, whether the services provided arecovered by the benefit plan, whether the services were rendered during aperiod the patient was covered by the benefit provider, and whether theservice provider is authorized to provide services for persons coveredby that benefit plan, the benefit provider will pay the health careservice provider for the service provided at a specified rate. However,if any of the numerous requirements are not met, the medical claim ofthe health care service provider is not submitted or processed forpayment. When such a query for eligibility status is rejected, thehealth care service provider can seek to recover the fees due from thepatient, or from a patient's secondary benefit provider, if any exists.Often, when all other recourse has been exhausted, the service providermust absorb the loss and not receive payment for the services provided.

Denial of eligibility for treatment is typically because the serviceprovider is not authorized to provide service for persons covered by aspecific benefit plan, the service provided is not covered by thebenefit plan of the patient, the date on which the service was providedwas not a covered date, or the patient is not covered by the benefitplan. In many cases, the denial is because the information entered onthe medical claim submitted to the benefit provider by the serviceprovider cannot be correlated with the information in the benefitprovider's database, and therefore the medical claim is returned asineligible. In reality, in many of these situations, thepatient/service/date/service provider information comprises eligiblemedical claims within the scope of the benefit plan, but there is amistake or difference in the information on the medical claim and theinformation in the benefit provider's database, and so the medical claimis not considered eligible for reimbursement.

Additionally, while in many cases a medical claim 100 must be submittedwithin a certain time period after service is rendered, if the patientbecomes eligible retroactively, but after the allowed time period forfiling medical claims, a request can be made for payment for servicesthat were rendered that would be covered by the benefit plan. Thus, itmay be important to make inquiries as to eligibility status at frequentintervals to determine if a person is eligible while still within thetime period during which a request for payment can be made.

Under certain new laws and regulations, such as the Health InsurancePortability and Accountability Act (HIPAA), which regulates theinsurance benefit industry, service providers are authorized to accessthe benefit providers' databases 500, or to enable other parties toaccess the benefit providers' databases 500 on their behalf, to makeinquiries as to patient eligibility status. In some instances, ifcertain specifications are met as to the software used and otherrequirements, the benefit provider must make the information in itsdatabase available for such inquiries without charge. Additionally,HIPAA mandates that benefit providers' databases should provide certainstandard responses for cases where an eligibility query matches with apatient in a particular benefit provider's database, such thatrecognized patients are clearly identified even in cases where activeeligibility covering the service dates does not exist. The purpose ofthis response is merely to alert the inquirer that the patient isrecognized by the benefit provider's database. As an example, thesoftware 10 described herein may be fully compliant with the new lawsand regulations.

B. OPERATION

As shown in FIG. 1B, the software 10 may provide an analyzer 102 forconverting and sorting a service provider's medical claims 100 and forgenerating a file of medical claims 200 in a form capable of beingcompared to the database of benefit providers 500 to find records 510that match. The first step in the process encompassed by the software 10is the generation of a file 200 containing the information from theservice provider's unpaid medical claims 100 by the analyzer 102. Table1 shows an example of the fields of a medical claim 100, although itshould be appreciated that a variety of different numbers andarrangements of fields is possible. The exact fields 100 a to 100 ncontained in each medical claim record 100 may vary, depending on whatinformation is available in the service provider's records, and theinformation kept in the benefit provider's database 500.

TABLE 1 Field Example Claim data Patient ID No. 12345678 Patient LastName Smith Patient First name John Patient Middle Name Q. Patient Dateof Birth Jan. 01, 2000 Patient Address 123 Main St. Patient City AnytownPatient State Texas Patient Zip Code 12345 Patient Telephone No. (214)867-5309 Benefit Plan Name Medicaid Benefit Plan No. Type B Insured'sname Smith, John Q. Date of Service Jan. 28, 2004 Service Code ABC1234Service Description Emergency Room Visit Charge Amount 250.00 AmountPaid 000.00 Balance Due 250.00

In another embodiment, the software 10 as described herein may sort theservice provider's claims 100 by any of the fields 100 a to 100 ncontained in each claim 100, such as, for example, a unique patientidentifier and/or selected patient demographics (for example, name,social security number, date of birth, or the like). Such sorting of themedical claims may create one or more groupings of medical claimswherein each such grouping constitutes a cluster of patient claims. Thesoftware 10 may then create a composite medical claim 100 containing allof the relevant fields 100 a to 100 n within the cluster, and ananalyzer 102 may then convert and sort a service provider'snon-clustered medical claims 100 and composite medical claims 100 forgenerating a file of claims 200 in a form capable of being compared tothe database of benefit providers 500 to find records 510 that match.Composite medical claims 100 may be used with a Date of Servicedescription set to the prior seven days, though a person having ordinaryskill in the art will understand that any date prior to the date of thequery may be used in creating the composite medical claim 100.

Once the medical claim records 100 have been converted by the analyzer102 to the proper format in file 200, the software 10 may employ one ormore processing queries 300. These processing queries 300 utilizemedical claim records 100 and/or composite medical claims 100 withinfile 200 as the basis of the collection of one or more queries 300′,300″, and 300′″, and so on of the benefit provider's database 500. Eachmedical claim record 100 and/or composite medical claim 100 in the file200 may be in the same format so the information therein can be comparedto the records 510 in the benefit provider's database 500. The file 200may be saved by the software 10 in a format that can be read andcompared to the fields in the benefit provider's database 500.

The queries 300 contain instructions for comparing the fields 100 a to100 n of each medical claim or composite medical claim 100 in the file200 with the corresponding fields 510 a to 510 n of each record 510 inthe benefit provider's database 500 of covered persons to determine ifthey contain matching information. Table 2 is an example of some of thetypes of queries 300 that can be executed using the software 10described herein.

TABLE 2 Name Query Description MC Medicaid number only SSN SocialSecurity number only MC SSN Medicaid & Social Security MC DOB Medicaid &Date of Birth MC FNLN Medicaid & First name, Last name SSN DOB SocialSecurity & Date of Birth SSN FNLN Social Security & First name, Lastname SSN LNFNINV SSN and First, Last Name switched SSN LNMN SSN & Lastname, Middle name replacing First name DOB FNLN G F Date of Birth &First name, Last name & Gender (Female) DOB FNLN G M Date of Birth &First name, Last name & Gender (Male) SSN LN Social Security & Last nameSSN LNFNMIa Social Security & full name, MI SSN LNFNMIb Social Security& last name, first name + MI SSN LNFNMIc Social Security & last name,first name, + “ ” + MI SSN LNFNMId Social Security & last name + MI,first name DOB FN4LN DOB & first name, 1^(st) 4 letters of last name SSN4LN SSN & 1^(st) 4 letters of last name SSN LNFNMIe Social Security &last name + MI, first name DOB LNFNMIa Date of Birth & full name, MI DOBLNFN MIb Date of Birth & last name, first name + MI DOB LNFN MIc Date ofBirth & last name, first name + “ ” + MI DOB LNFN MId Date of Birth &last name + MI, first name DOB LNFN MIe Date of Birth & last name + “” + MI, first name DOB LNFN Date of Birth & last name, first name DOBLNFNINV Date o Birth & last name, first name switched DOB LNMN Date ofBirth & last name, middle name replacing first name DOB LNFNHA DOB &first name, 1^(st) half of hyphenated last name DOB LNFNHB DOB & firstname, 2^(nd) half of hyphenated last name DOB LNFNHAB DOB & first name,hyphen/space removed from last name DOB LNFNHS DOB & first name,hyphen-> space in last name SSN LNFNHA SSN & first name, 1^(st) half ofhyphenated last name SSN LNFNHB SSN & first name, 2^(nd) half ofhyphenated last name SSN LNFNHAB SSN & first name, hyphen/space removedfrom last name SSN LNFNHS SSN & first name, hyphen -> space in last name

A query 300 can ask about a variety of information in various fields 510a-n in the records 510 in the benefit provider's database 500. Forexample, a query 300′ could be as simple as checking to determine if theinformation in the patient identification number field 100 a of aservice provider's medical claim record 100′ in the file 200 of claimsmatches the identification number field 510 a in any records 510 in thebenefit provider's database 500. Or, a query 300″ could be more complex,and search for a variety of information matches, or partial matches, inmultiple fields in the records 510 in the benefit provider's database500. For example, the query 300″ could check for medical claims 100, orcomposite medical claims 100, and records 510 in which both the date ofbirth fields 100 b, 510 b in the file 200 and benefit provider'sdatabase 500 match, and also the first 4 letters of the last name fields100 c, 510 c match. It can be appreciated that a very large variety ofqueries 300 can be configured and used. The queries 300 can be virtuallyunlimited, as long as the information to be queried is available in theservice provider's records 100 and in the benefit provider's database500.

The software 10 described herein may perform more queries 300, and moreflexible queries, of the benefit provider's database 500, and mayperform comparison and analysis to determine if there is a match betweena medical claim 100, or composite medical claim 100, and a record in thebenefit provider's database 500. It is this expanded scope andflexibility that results in a greater number of matched records thanwould otherwise be found.

If a query 300 matches a composite medical claim 100 to a record 510 inthe benefit provider's database 500, then the software 10 describedherein may add the underlying constituent medical claims 100 of theassociated cluster to the file of remaining medical claims 200 to becompared to the benefit provider's database 500. Under the provisions ofHIPAA, benefit providers' databases should provide certain affirmativestandard responses for cases where an eligibility query matches with apatient in a particular benefit provider's database, and recognizedpatients are clearly identified even in cases where active eligibilitycovering the service dates does not exist. The software 10 may becapable of recognizing these affirmative standard responses, and whensuch responses are received, may add the underlying constituent medicalclaims 100 to the file of remaining medical claims 200 to be compared tothe benefit provider's database 500. The clustering of medical claims100 is useful because the same number of medical claims 100 may becompared with the benefit provider's database 500 using a smaller numberof queries 300.

The software 10 described herein, in addition to finding matchingrecords, because it does more queries 300, can also determine additionaldata about a medical claim 100, such as whether or not the claimedservice is covered, the balance due on a medical claim 100, and even theamount of the balance due that is eligible for reimbursement. Asurprising number of matches between service provider medical claims 100and benefit provider databases 500 were found using embodiments of thesoftware 10 described herein that were not found using other software.In one instance, a hospital, making just one set of queries 300,identified several million dollars in medical claims that were notpreviously found to be eligible for reimbursement.

Repeated execution of the queries 300 of the same benefit provider'sdatabase 500 at regular intervals, such as monthly or bi-weekly,continued to reveal medical claims 100 that were not eligible forreimbursement at the time the initial queries 300 were run, butsubsequently became eligible for reimbursement. It can be appreciatedthat if these queries 300 were not subsequently run, the medical claims100 found would not be reimbursed. Additionally, because there istypically a limited time period after a patient becomes eligible forbenefits in which a medical claim 100 can be filed, it can beappreciated that if the queries 300 are not run at regular intervals,while matches could be found, they might be found too late for theservice provider to seek reimbursement.

Additionally, it can be appreciated that identifying medical claimswhich would qualify for reimbursement under certain government medicalprograms would be important, even if reimbursement were not actuallyreceived, in order to help determine qualification for other governmentprograms, and/or whether budget and funding estimates are accurate. Forexample, hospitals and other service providers that provide services toa large number of patients qualifying for Medicaid and/or Medicare couldreceive funding from another government fund for service providers whotreat a disproportionate share of low-income patients. By using theresults of the queries to identify qualifying patients, even if recoverycannot be made under the initial program, the treatment can be used forreporting and submitting requests for funding under secondary programs,such as the disproportionate share programs. For example, some patientswho are treated who might qualify for reimbursement under stategovernment managed programs may be from out of state, and therefore sucha medical claim 100 may not be entitled to reimbursement. However, suchunreimbursed medical claims may be used to qualify the service providerfor reimbursement under secondary programs. The software 10 can be usedto provide reports as to the patients treated, anticipated and projectedfunding, whether the service provider is treating more or lesslow-income patients than projected, and potential entitlement for futureprograms. This information is very useful to a service provider, asknowing this information can be used to project budgets, deficits andqualification for additional funding.

Typically, the first query 300′ might be to check for a person in thebenefit provider's database 500 having a social security number/otherunique identification number, and/or last name and first name thatmatches that of a patient for whom the hospital had provided services.Exactly which query 300 would be the first query 300′ would depend onhow the benefit provider structures its database records.

Additionally, a query 300 can also be a series of sequential queries.For example, a query 300′ could be done to match the patientidentification field 100 a in a medical claim 100 with the patientidentification field 510 a for any matching record 510 from the benefitprovider's database 500. If the patient ID number matches, then a secondquery 300″ can be made between these matching records found in responseto query 300′ to determine if the date on which the service was providedfalls within the dates of coverage provided by the benefit provider tothat patient, and only if the answer to the second query 300″ is alsopositive will the record be set aside in the file 400 for furtherprocessing. Alternatively, the system could be configured so that ifthere is a match in the first electronic query 300′, the records couldbe flagged and set aside, and the second query 300″ could be doneseparately in a different query 300 or in or by a different system, orcould even be done manually.

Note the software 10 can be configured so that all the queries 300 whichare selected to be made could be run simultaneously or sequentially, orthey could be grouped together and run sequentially. The purpose ofdifferent orders of queries or grouping of queries is to maximizeefficiency of the software 10. The process in making such queries 300 ofgenerally comparable records can also employ a variety of techniques,such as fuzzy and soundex searches, for example. It should beappreciated that the queries 300 selected, the order in which they areperformed, and the groupings of queries can be adapted or modified,depending on results returned from the queries 300.

Once the queries 300 to be run have been selected and generated by thesoftware 10, the benefit provider's database 500 is accessed, and thesoftware 10 executes the first selected query 300′ thereon. If one ormore matching records 510′ are found in the benefit provider's database500 for a medical claim 100′, the medical claim 100′ is distinguished orflagged, removed from the file 200, and stored separately from theremainder of the medical claims 100 in the service provider's database200 in a file 400, along with the information from matching records 510′from database 500. The purpose of removing the matched medical claim100′ from the file 200 is to streamline efficiency of the queries 300.Because one or more matches have already been made, there is no need tomake additional queries 300 about this particular medical claim 100′.The query 300′ will then be performed for the next medical claims 100″in the file 200 of service provider's medical claims, if any. If matchesare found, then this medical claim 100″ and the matching records 510″from the benefit provider's database 500 will also be stored in the file400. If no match is found for medical claim 100″, the medical claimremains in the file 200. Query 300′ will be performed for each medicalclaim 100 in the file 200.

The software 10 may format composite medical claims 100′ in the EDI 270batch file format recognized by HIPAA, for example. A query 300 may thenbe used to transmit the EDI 270 batch file, representing the compositemedical claim 100′, to the benefit provider's database 500, which underthe provisions of HIPAA should then return an EDI 271 batch fileresponse stating that the patient was either found, or not found, in thebenefit provider's database 500. If the benefit provider's database 500recognizes the patient associated with composite medical claim 100′,then the composite medical claim 100′ is removed from the file 200, andeach clustered medical claim 100 represented by the composite medicalclaim 100′ is added to file 200. The added clustered medical claims 100may then be run against the benefit provider's database 500 using theselected queries 300 as described above.

If, after making the initial query 300′ of the benefit provider'sdatabase 500, there are still medical claims 100 in the serviceprovider's file 200 that were not correlated with records 510 in thebenefit provider's database 500, there are a variety of optionalprocesses that could occur. In some embodiments, no additional actionscould be taken, and the medical claims 100 remaining in the file 200would remain in an ineligible status.

Alternatively, if there are additional queries 300″, 300′″, etc., thatare in the selection of queries 300 to be made, the next query 300″ canbe made of the benefit provider's database 500 to try and findadditional matches with medical claims 100 in the service provider'smedical claims file 200. Again, for each medical claim 100 in the file200, query 300″ will be made of the benefit provider's database 500, andif any matches are found, that medical claim 100′″ is flagged, placed inthe file 400 and removed from the file 200 of unmatched medical claims.The software 10 then continues to make the same query 300″ for eachremaining medical claim 100 in the service provider's file 200. Thiscycle of querying/record flagging will continue until all medical claims100 in the service provider's medical claims file 200 have been matchedto at least a record 510 in the benefit provider's database 500, oruntil all queries specified have been made of the benefit provider'sdatabase 500 for all medical claims 100 in the service provider'smedical claims file 200.

Once all the queries 300 of the benefit provider's database 500 havebeen run, the file 400 of all matched records is generated. In the file400, each medical claim 100 is associated with the related matchingrecord 510 from the benefit provider's database 500. For example,medical claim 100′, from the file 200 which was associated with a record510′ from the benefit provider's database 500, will be grouped togetherin the file 400. The file 400 can be saved on a computer, or deliveredvia other methods, such as via the internet, as an attachment to ane-mail, as a facsimile, or as a physical document. A report 450 ofcontents of the file 400 can be generated and provided to the serviceprovider so that the eligible medical claims can be submitted forpayment by the service provider.

The report 450 can be delivered to the service provider in a variety ofmethods, depending on their preference, including delivery by e-mail, inpaper form, or by internet or a variety of other forms. Reports 450 caninclude a variety of information such as the information from eachmedical claim 100 in the service provider's database for which anymatching record 510 in the benefit provider's database 500 was found.FIGS. 2A, 2B, and 2C show samples of some of the many reports that canbe generated using the software described herein.

As can be seen in the report in FIG. 2A, a listing is provided ofmedical claims for which a match was found in the benefit provider'sdatabase. Any information in the service provider's database that wasincorrect or differed from that in the benefit provider's database maybe shown in different print for assistance in easily identifying theproblem so the medical claim can be corrected.

As can be seen, the report 450 shown in FIG. 2A is organized so that theservice provider can easily review the information to determine thoserecords having errors, and exactly what the errors are, so the medicalclaims can be corrected and resubmitted. In contrast, other existingsoftware generated reports that simply listed names and identificationnumbers of patients for which a match was found in the benefitprovider's database 500. No sorting of records was done as in thereports of the present disclosure, and no additional information wasprovided from the benefit provider's database 500, such as eligibilitydates and billing deadlines, so additional manual analysis was requiredto determine if a medical claim could be submitted for payment.Additionally, because the other existing software did not do anymulti-field comparisons or partial matches with analysis, records suchas the first three shown in the sample report in FIG. 2A would not havebeen discovered at all.

A record such as the fourth record shown in the sample report in FIG.2A, which would have appeared as eligible for reimbursement using otherexisting software, which only checked for a match of identifyinginformation for the patient, would have resulted in a medical claim thatwas submitted being rejected, because the service type code was enteredincorrectly. Using the software 10 described herein, which checks to seeif the service rendered is eligible for reimbursement, would find theincorrect service code, which could be corrected before the medicalclaim 100 was submitted for reimbursement.

The fifth record shown in the sample report in FIG. 2A shows a medicalclaim 100 for which partial payment has been received, but for whichthere is still an outstanding balance. The software described herein hasperformed analysis to determine that the patient is covered by thebenefit provider, and that the service is eligible for reimbursement.Therefore, the service provider can submit the medical claim 100 to seekto recover the outstanding balance. The report also shows the amount ofthe outstanding balance that is eligible for reimbursement. In thiscase, it is less than the full amount because the deductible for thebenefit provider has not yet been met by this patient. This medicalclaim is also an example of a medical claim which has become eligiblefor benefits since the last time a report was run, and lists the date bywhich any claim must be made.

The last entry on the sample report of FIG. 2A shows a medical claim 100that would have been qualified for reimbursement, had it been found andsubmitted in a timely manner. Such results would occur if the queries300 described herein were not made on a regular basis.

FIG. 2B shows a pie chart break-out of an example of one instance inwhich the software 10 described herein was used showing the amount ofmedical claims eligible for reimbursement for a benefit provider, brokenout by class of benefit provider, the number of medical claims for eachclass, and the amount of money for the medical claims for each class.Additional information from the service provider's and benefitprovider's records that would be useful to the service provider insubmitting the medical claim is also provided, such as the deadline, ifany, by which the medical claim must be submitted.

FIG. 2C shows a report that provides information about medical claimeligibility verification for a variety of service providers, includingthe amounts identified for the medical claims, broken out for queriesmade on a regular basis. As can be seen, while the number for subsequentqueries 300 typically decreases, it can be seen that additional eligiblemedical claims are identified when the software 10 is used to makesubsequent queries 300.

It should be appreciated that a variety of different reports, reportformats, and information can be used, depending on the needs of theservice provider. The information in the reports 450 can be used for avariety of functions, such as to track errors, and possibly reducesimilar future errors made when submitting medical claims. Additionally,the reports 450 can be used to monitor query results to determine theeffectiveness of a particular query 300. If a particular query 300 doesnot ever produce any record matches, a decision could be made to notcontinue to make that query 300, or to enhance it in some way so as toincrease the likelihood of obtaining a match.

Depending on the benefit provider's system, medical claims for which amatch was found can be filed on-line, and/or a manual submission ofmedical claims for which payment is requested can be made.

The software 10 can be modified continually or periodically to ensurecompliance with various local, state and/or federal laws, depending onwhere it is used. Additionally, because the world of medical service andbenefit providers is rapidly and continuously changing and evolving, thesoftware 10 described herein may be designed to be flexible and adapt toongoing changes in the industry.

C. EXAMPLES

It is appreciated that some examples may be helpful in illustrating thefeatures of the system and method described herein. If a serviceprovider, such as a hospital, had a large number of medical claims 100for services it had provided to patients (for example, an emergency roomvisit, a hospital stay, or the like), the software 10 could be used toinquire as to the status of the medical claims 100. The software 10would first be used to generate a file 200 in the appropriate form thatcontained information for each medical claim 100. For purposes of thisexample, it is assumed that there are 90 (ninety) medical claims 100 inthe file 200.

The software 10 may also be used to develop a series of one or morequeries 300 that could be made of the benefit provider's database ofmembers to find members of the benefit provider's plan for whom theservice provider had rendered service, but has not yet been reimbursed.Again, only for purposes of this example, it is assumed that there aretwo queries to be made against the benefit provider database 500,sequentially, and a third query to be made for all records which wereentered in file 400.

Typically, the first query 300′ might be to check for a person in thebenefit provider's database 500 having a social security number/otherunique identification number, and/or last name and first name thatmatches that of a patient for whom the hospital had provided services.Exactly which query 300 would be the first query 300′ would depend onhow the benefit provider structures its database records.

Such an initial standard query is useful to patients eligible forreimbursement. In some situations, there is a delay in a patient beingentered into a benefit provider's database, so if the medical claim issubmitted to the benefit provider for payment before the patient hasbeen added to the database, the medical claim 100 status will bereturned as ineligible. Additionally, for some medical benefit programs,such as Medicaid and the Consolidated Omnibus Budget Reconciliation Act(COBRA), coverage can be retroactive. Similarly, in these situations,the patient may not appear in the database of persons qualifying forbenefits under that plan when the patient is treated, or the databasemay indicate that the patient was not covered on the date the servicewas rendered. However, if the patient is added to the benefit provider'sdatabase subsequently, the medical claim will only be shown as“eligible” if the medical claim is re-submitted after the patient is inthe benefit provider's database 500. In some instances, it has beenfound that several years can elapse before a medical claim 100 becomeseligible for reimbursement. However, in many cases, there is only alimited time allowed after a patient becomes eligible that medicalclaims 100 can be submitted to the benefit provider. Thus, queries 300of the benefit provider's database 500 must be made on a regular basisso that eligible medical claims 100 can be identified in a timelymanner, while the medical claims 100 can still be filed.

Another example of situations in which the patient may not appear in thebenefit provider's database 500 when a medical claim is first submittedis for newborn babies. Such patients do not always have a unique IDnumber, such as a social security number, at birth. In some cases, thereis even a delay in the patient being given a name, and the hospitalrecords may simply refer to the child as “Baby Boy Smith.” Thus, thehospital may not have the proper information available to it to be ableto generate a medical claim with information that matches the benefitprovider's database 500. Even if the hospital had the correct name oridentifying information, these patients are not added to the insurer'sdatabase until after the child is born, and there is typically a delayin such information getting entered into the database. Thus, thehospital could submit a medical claim 100 immediately after the child isborn, and there could be no related record 510 in the benefit provider'sdatabase 500 at that time. Thus, these medical claims 100 are often notpaid because they cannot be matched up with a patient in the benefitprovider's database 500. Again, making eligibility inquiries of thebenefit provider's database on a regular basis will reveal that thepatient has been added to the database 500 and the medical claim 100 iseligible for reimbursement.

Another example of medical claims 100 that this query 300′ might find amatch for would be an instance where the benefit provider matchesrecords by patient name, rather than patient identification, and thebenefit provider has a patient in its database 500 as John Smith, butthe service provider submitted a medical claim for service provided toJohn Smithe. Because the benefit provider did not find John Smithe inits database, it originally rejected the medical claim as ineligible;however, because the patient IDs match, this query would make a match.

Once the queries 300 have been selected, the software 10 can beconfigured to run the selected queries 300 against the benefitprovider's database 500 to find records that match any of the medicalclaims 100 in the file of the service provider's unpaid claims 200.Again, for purposes of this example, it is assumed that the first query300′ is to find an exact match between the patient ID fields of anymedical claim 100 in the file of the hospital's medical claims 200, andany patient record 510 in the benefit provider's database 500. Forexample, assume that when query 300′ has been run, and the data in eachof the ninety medical claims 100 in the service provider's file 200 hasbeen compared to the records 510 in the benefit provider's database 500,twenty of the medical claims 100 are found to have matching records 510in the benefit provider's database, therefore being eligible forreimbursement. When a match is found for a medical claim 100′ in thebenefit provider's database, that medical claim 100′ and the informationfrom the matching record 510′ in the benefit provider's database 500 isplaced in a file 400. Each medical claim 100 which has been matched to arecord 510 from the benefit provider's database 500 is removed from thefile 200 after query 300′ has been run and completed. Thus, after thefirst query 300′ has been run, only seventy medical claims 100 willremain in the file 200.

For purposes of this example, assume the second query 300″ is a query tofind medical claims 100 in the seventy remaining medical claims in thefile 200 for which the date of birth field is the same as the date ofbirth field in a record 510 in the benefit provider's database 500, thefirst name fields are the same, and the first four letters of the lastname field are the same. This query would find patients for whom thepatient ID was entered incorrectly, but the name and date of birthinformation was correct. Thus, if for patient Thomas Jones, his IDnumber was incorrectly entered in the service provider's medical claimas 12345679, but the actual ID number was 12345678, the first query 300′would not find a matching record 510 in the benefit provider's database500. However, the second query 300″ would find a matching record 510.

After the first query 300″ has been run, the second query 300″ is runfor the remaining seventy medical claims 100 in the file 200. Assumethis query results in another twenty medical claims 100 being matchedwith one or more records 510 in the benefit provider's database 500.Each of these twenty medical claims is also removed from file 200 andplaced in file 400, leaving only fifty medical claims 100 in the file200. It can be appreciated that with queries 300″ such as this, multiplematches could be found with persons having the same date of birth, firstname, and last four digits of the last name, and therefore, multiplerecords 510 could be returned that potentially match a medical claim100.

When all the queries 300 have been run, the software 10 will exit thequery of the benefit provider's database 500, and a file 400 of allmatched records is generated. In the case of this example, file 400contains forty medical claims 100 for which one or more matches havebeen made in the benefit provider's database 500. The file 400 containsthe information from each medical claim 100 for which a matching record510 in the benefit provider's database 500 was found, and theinformation from the matching record(s) 510 in the benefit provider'sdatabase. A report 450 of contents of the file 400 can be generated andprovided to the service provider so that the matched medical claims canbe submitted to the benefit provider.

However, in the case of this example, the software runs a query 300′″ onall forty records in the file 400 to determine if the date by which amedical claim must be submitted for reimbursement is later than thepresent date. If not, that claim could be flagged in the file 400 asbeing a past deadline medical claim. Or, it could be a query that wouldcheck for additional matching fields between medical claims 100 thathave generated more than one matching record 510 from the benefitprovider's database 500. It can be appreciated that this query couldhave been made as part of the first or second queries 300′, 300″ of thebenefit provider's database 500, or as a separate query 300 of thebenefit provider's database 500. However, again, only for the purposesof this example, assume that it was found to be much more efficient tomake this date query 300′″ after file 400 had been generated, ratherthan as a query to the benefit provider's database 500. Additionally,such information about medical claims qualifying for payment could beimportant for tracking whether a health care service provider qualifiesfor reimbursement from other programs, such as disproportionate shareMedicaid or Medicare reimbursement funds, as discussed above. If thisquery was performed before the medical claim 100 was placed in the file400, the medical claim 100 might not be placed in the file 400, andtherefore it could be difficult to track this type of information whenpreparing reports to determine qualification for the additionalprograms. Alternatively, it can be appreciated that further inquiriessuch as this could be made manually upon review of the report 450 ofmatching files 400. Again, how such analysis is performed depends on thespecific needs of a user.

If appropriate, additional analysis can be made of the serviceprovider's medical claims 100 and any matching records 510 from thebenefit provider's database 500 to determine if there are additionalfields that match between the record in the benefit provider's databaseand the medical claim to ensure the patient is the same entity. Forexample, if multiple records 510 are returned that same date of birth,first name, and first 4 digits of the last name, additional analysis canbe done to look for additional matches in other fields, or determine theprobability that a specific record 510 matches a specific medical claim100′.

In another embodiment, some of the medical claims 100 in the examplesdiscussed above may be clustered together based on a unique patientidentifier and/or patient demographics (name, social security number,date of birth, or the like) and a composite medical claim 100 may becreated which contains this patient information. If a query 300 returnsa matching record 510 from the benefit provider's database 500, or ifthe database 500 recognizes the patient as per HIPAA protocols, forexample, then the software 10 may add the underlying clustered medicalclaims 100 to the file of remaining claims 200 and may then run everyremaining medical claim 100 against the database 500 to determinewhether a patient claim is eligible for reimbursement and can besubmitted to the benefit provider for payment. In this way, the samenumber of medical claims 100 can be compared to the database 500 usingfewer queries.

In one arrangement, queries 300 can be run of the benefit provider'sdatabase 500, with charges being incurred on a per query basis. Inanother arrangement, because the software 10 complies with therequirements of the new laws governing such queries 300, the queries 300can be run without charge for the number of queries run, or the numberof times queries are run. If the queries 300 are made by a third partyon behalf of the service provider, payment to the third party can bemade based on the number of medical claims 100 that are matched todatabase records 510, and for which payment is received by the serviceprovider.

It is understood that the present invention can take many forms andembodiments. Accordingly, several variations may be made in theforegoing without departing from the spirit or the scope of theinvention. Having thus described certain embodiments, it is noted thatthe embodiments disclosed are illustrative rather than limiting innature and that a wide range of variations, modifications, changes, andsubstitutions are contemplated in the foregoing disclosure and, in someinstances, some features of the present invention may be employedwithout a corresponding use of the other features. Many such variationsand modifications may be considered obvious and desirable by thoseskilled in the art based upon a review of the foregoing description ofillustrative embodiments. Accordingly, it is appropriate that theappended claims be construed broadly and in a manner consistent with thescope of the invention.

1-6. (canceled)
 7. A method for identifying medical claims eligible forreimbursement, comprising: sorting medical claims of a service providerinto clusters of medical claims and non-clustered medical claims,wherein each of said clusters comprises a group of constituent medicalclaims all relating to the same patient; creating a composite medicalclaim for each of said clusters, wherein each said composite medicalclaim comprises data representative of all said constituent medicalclaims within the respective cluster; executing a query against thebenefit provider's database for each said composite medical claim andeach said non-clustered medical claim; receiving an indication as towhether the benefit provider's database contains a record that isresponsive to each said query; for each said indication that isaffirmative with respect to one of said non-clustered medical claims forwhich the benefit provider's database comprises one or more matchingrecords, placing said one of said non-clustered medical claims and saidone or more matching records in a file; for each said indication that isaffirmative with respect to one of said composite medical claims,executing an additional query against the benefit provider's databasefor each said constituent medical claim within the respective clusterassociated with said one of said composite medical claims; and for eachsaid additional query associated with one of said constituent medicalclaims for which the benefit provider's database comprises one or moreadditional matching records, placing said one of said constituentmedical claims and said one or more additional matching records in saidfile.
 8. The method of claim 7 further comprising: submitting saidnon-clustered medical claims and said constituent medical claims forwhich the benefit provider's database comprises one or more matchingrecords to the benefit provider for reimbursement.
 9. The method ofclaim 7 further comprising: generating a report indicative of adifference in information between one of said medical claims of theservice provider and one of said matching records of the benefitprovider.
 10. The method of claim 9 wherein said report furthercomprises an eligibility date for said one of said medical claims. 11.The method of claim 10 wherein said eligibility date is retroactive. 12.The method of claim 9 wherein said report further comprises a deadlineby which said one of said medical claims must be submitted forreimbursement.
 13. The method of claim 9 wherein said report furthercomprises an amount of an outstanding balance eligible for reimbursementwith respect to a medical claim for which a partial payment has beenmade.
 14. The method of claim 9 wherein said report further comprises anindication of an incorrect service code.